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Preface  &  Acknowledgements 


Welcome  to  our  Ninth  Annual  Acquisition  Research  Symposium!  This  event  is  the 
highlight  of  the  year  for  the  Acquisition  Research  Program  (ARP)  here  at  the  Naval 
Postgraduate  School  (NPS)  because  it  showcases  the  findings  of  recently  completed 
research  projects — and  that  research  activity  has  been  prolific!  Since  the  ARP’s  founding  in 
2003,  over  800  original  research  reports  have  been  added  to  the  acquisition  body  of 
knowledge.  We  continue  to  add  to  that  library,  located  online  at 

www.acquisitionresearch.net,  at  a  rate  of  roughly  140  reports  per  year.  This  activity  has 
engaged  researchers  at  over  60  universities  and  other  institutions,  greatly  enhancing  the 
diversity  of  thought  brought  to  bear  on  the  business  activities  of  the  DoD. 

We  generate  this  level  of  activity  in  three  ways.  First,  we  solicit  research  topics  from 
academia  and  other  institutions  through  an  annual  Broad  Agency  Announcement, 
sponsored  by  the  USD(AT&L).  Second,  we  issue  an  annual  internal  call  for  proposals  to 
seek  NPS  faculty  research  supporting  the  interests  of  our  program  sponsors.  Finally,  we 
serve  as  a  “broker”  to  market  specific  research  topics  identified  by  our  sponsors  to  NPS 
graduate  students.  This  three-pronged  approach  provides  for  a  rich  and  broad  diversity  of 
scholarly  rigor  mixed  with  a  good  blend  of  practitioner  experience  in  the  field  of  acquisition. 
We  are  grateful  to  those  of  you  who  have  contributed  to  our  research  program  in  the  past 
and  hope  this  symposium  will  spark  even  more  participation. 

We  encourage  you  to  be  active  participants  at  the  symposium.  Indeed,  active 
participation  has  been  the  hallmark  of  previous  symposia.  We  purposely  limit  attendance  to 
350  people  to  encourage  just  that.  In  addition,  this  forum  is  unique  in  its  effort  to  bring 
scholars  and  practitioners  together  around  acquisition  research  that  is  both  relevant  in 
application  and  rigorous  in  method.  Seldom  will  you  get  the  opportunity  to  interact  with  so 
many  top  DoD  acquisition  officials  and  acquisition  researchers.  We  encourage  dialogue  both 
in  the  formal  panel  sessions  and  in  the  many  opportunities  we  make  available  at  meals, 
breaks,  and  the  day-ending  socials.  Many  of  our  researchers  use  these  occasions  to 
establish  new  teaming  arrangements  for  future  research  work.  In  the  words  of  one  senior 
government  official,  “I  would  not  miss  this  symposium  for  the  world  as  it  is  the  best  forum 
I’ve  found  for  catching  up  on  acquisition  issues  and  learning  from  the  great  presenters.” 

We  expect  affordability  to  be  a  major  focus  at  this  year’s  event.  It  is  a  central  tenet  of 
the  DoD’s  Better  Buying  Power  initiatives,  and  budget  projections  indicate  it  will  continue  to 
be  important  as  the  nation  works  its  way  out  of  the  recession.  This  suggests  that  research 
with  a  focus  on  affordability  will  be  of  great  interest  to  the  DoD  leadership  in  the  year  to 
come.  Whether  you’re  a  practitioner  or  scholar,  we  invite  you  to  participate  in  that  research. 

We  gratefully  acknowledge  the  ongoing  support  and  leadership  of  our  sponsors, 
whose  foresight  and  vision  have  assured  the  continuing  success  of  the  ARP: 

•  Office  of  the  Under  Secretary  of  Defense  (Acquisition,  Technology,  &  Logistics) 

•  Director,  Acquisition  Career  Management,  ASN  (RD&A) 

•  Program  Executive  Officer,  SHIPS 

•  Commander,  Naval  Sea  Systems  Command 

•  Program  Executive  Officer,  Integrated  Warfare  Systems 

•  Army  Contracting  Command,  U.S.  Army  Materiel  Command 

•  Office  of  the  Assistant  Secretary  of  the  Air  Force  (Acquisition) 
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•  Office  of  the  Assistant  Secretary  of  the  Army  (Acquisition,  Logistics,  & 
Technology) 

•  Deputy  Director,  Acquisition  Career  Management,  U.S.  Army 

•  Office  of  Procurement  and  Assistance  Management  Headquarters,  Department 
of  Energy 

•  Director,  Defense  Security  Cooperation  Agency 

•  Deputy  Assistant  Secretary  of  the  Navy,  Research,  Development,  Test  & 
Evaluation 

•  Program  Executive  Officer,  Tactical  Aircraft 

•  Director,  Office  of  Small  Business  Programs,  Department  of  the  Navy 

•  Director,  Office  of  Acquisition  Resources  and  Analysis  (ARA) 

•  Deputy  Assistant  Secretary  of  the  Navy,  Acquisition  &  Procurement 

•  Director  of  Open  Architecture,  DASN  (RDT&E) 

•  Program  Executive  Officer,  Littoral  Combat  Ships 

We  also  thank  the  Naval  Postgraduate  School  Foundation  and  acknowledge  its 
generous  contributions  in  support  of  this  symposium. 

James  B.  Greene  Jr.  Keith  F.  Snider,  PhD 

Rear  Admiral,  U.S.  Navy  (Ret.)  Associate  Professor 
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Panel  6.  Considerations  in  Acquiring  Open 
Architecture  Software  Systems 


Wednesday,  May  16,  2012 

1:45  p.m.  - 

Chair:  Captain  Joseph  J.  Beel,  USN,  Commanding  Officer,  Space  and  Naval 

3:15  p.m. 

Warfare  Systems  Center  Pacific 

A  Framework  for  Reuse  in  the  DoN 

Randy  Mactal,  Space  and  Naval  Warfare  Systems  Center  Pacific 

Lynne  Spruill,  APEO  Engineering  Support 

Addressing  Challenges  in  the  Acquisition  of  Secure  Software  Systems  With 
Open  Architectures 

Walt  Scacchi  and  Thomas  Alspaugh 

University  California,  Irvine 

Certifying  Tools  for  Test  Reduction  in  Open  Architecture 

Valdis  Berzins,  Naval  Postgraduate  School 

Joseph  J.  Beel — Captain  Joe  Beel  was  commissioned  from  the  U.S.  Naval  Academy  in  1985, 
earning  a  Bachelor  of  Science  degree  in  mechanical  engineering.  He  was  designated  a  Naval  Aviator 
in  September  1986.  He  completed  Fleet  Replacement  Pilot  training  with  HSL-31  in  May  1987  and 
joined  the  Sea  Snakes  of  HSL-33,  flying  the  SH-2F  Sea  Sprite  until  December  1989.  He  deployed  in 
the  USS  Kirk  (FF1067),  the  USS  Knox  (FF  1052),  the  USS  Francis  Hammond  (FF1067),  and  the  USS 
Sterrett  (CG  31),  including  service  in  Operation  Earnest  Will. 

He  attended  the  Naval  Postgraduate  School  in  Monterey,  CA,  from  1990  until  1992,  earning  a 
Master  of  Science  (with  distinction)  in  operations  research.  He  taught  in  the  U.S.  Naval  Academy 
Mathematics  Department  from  May  1992  until  May  1995  and  served  as  the  Fifth  Company  Officer 
from  August  1993  until  May  1995.  He  also  served  as  an  advanced  seamanship  and  navigation 
instructor  and  was  designated  a  craftmaster/yard  patrol  craft  officer-in-charge  afloat. 

Captain  Beel  completed  Fleet  Replacement  Pilot  training  with  HSL-41  in  February  1996  and 
joined  the  Battle  Cats  of  HSL-43,  flying  the  SH-60B  Sea  Hawk  until  1998.  He  deployed  in  the  USS 
Princeton  (CG  59). 

From  June  1998  until  August  1999,  Captain  Beel  served  as  the  training  and  education  program 
analyst  in  the  Assessment  Division  (N81),  Office  of  the  Chief  of  Naval  Operations.  He  served  in  a 
Federal  Executive  Fellowship  at  the  RAND  Corporation  in  Santa  Monica,  CA,  from  August  1999  to 
August  2000.  From  August  2000  until  September  2002,  he  served  in  the  USS  John  C.  Stennis  (CVN 
74),  including  service  in  Operations  Noble  Eagle  and  Enduring  Freedom.  He  served  as  officer-in- 
charge  of  Navy  Warfare  Development  Command,  Detachment  San  Diego,  from  October  2002  until 
August  2003.  He  served  as  commanding  officer  and  executive  officer,  Naval  Air  Technical  Data  and 
Engineering  Service  Command  (NATEC),  from  September  2003  until  September  2006. 

Most  recently,  Captain  Beel  served  four  years  in  the  Program  Executive  Office  (PEO),  Command, 
Control,  Communication,  Computers,  and  Intelligence  (C4I);  as  PEO  chief  of  staff  and  deputy  for 
Operations  from  October  2006  to  June  2008;  and  as  deputy  program  manager  of  the  Navy  Tactical 
Networks  Program  Office  from  June  2008  to  August  2010. 

Captain  Beel  is  a  member  of  the  Defense  Acquisition  Corps  and  is  Level  III  certified  in  Program 
Management,  Life  Cycle  Logistics  and  Production,  and  Quality  and  Manufacturing.  He  is  a  certified 
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Lean  Six  Sigma  Black  Belt.  He  led  a  continuous  process  improvement  project  that  was  awarded  a 
California  Council  of  Excellence  California  Team  Excellence  bronze  award  and  was  selected  to 
compete  for  the  American  Society  of  Quality’s  International  Team  Excellence  Award  at  the  201 1 
World  Conference  on  Quality  and  Improvement. 

Captain  Beel’s  awards  include  the  Meritorious  Service  Medal  (three  awards),  Air  Medal  (individual 
award),  Navy  Commendation  Medal  (five  awards),  Navy  Achievement  Medal,  and  various  unit, 
campaign,  and  service  awards.  He  has  also  received  the  Sikorsky  “Winged-S”  Lifesaving  Rescue 
Award. 
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Addressing  Challenges  in  the  Acquisition  of  Secure 
Software  Systems  With  Open  Architectures 


Walt  Scacchi — Scacchi  is  a  senior  research  scientist  and  research  faculty  member  at  the  Institute  for 
Software  Research,  University  of  California,  Irvine.  He  received  a  PhD  in  information  and  computer 
science  from  UC  Irvine  in  1981.  From  1981  to  1 998,  he  was  on  the  faculty  at  the  University  of 
Southern  California.  In  1999,  he  joined  the  Institute  for  Software  Research  at  UC  Irvine.  He  has 
published  more  than  150  research  papers  and  has  directed  60  externally  funded  research  projects.  In 
2012,  he  serves  as  general  co-chair  of  the  8th  IFIP  International  Conference  on  Open  Source 
Systems  (OSS2012).  [wscacchi@ics.uci.edu] 

Thomas  Alspaugh — Alspaugh  is  a  project  scientist  at  the  Institute  for  Software  Research,  University 
of  California,  Irvine.  His  research  interests  are  in  software  engineering,  requirements,  and  licensing. 
Before  completing  his  PhD,  he  worked  as  a  software  developer,  team  lead,  and  manager  in  industry, 
and  as  a  computer  scientist  at  the  Naval  Research  Laboratory  on  the  Software  Cost  Reduction,  or  A- 
7  project,  [thomas.alspaugh@acm.org] 

Abstract 

We  seek  to  articulate  and  address  a  number  of  emerging  challenges  in  continuously  assuring 
the  security  of  open  architecture  (OA)  software  systems  throughout  the  system  acquisition 
life-cycle.  It  is  now  clear  that  future  system  must  resist  coordinated  international  attacks  on 
vulnerable  software-intensive  systems  that  are  of  high  value,  and  control  complex  systems. 
But  current  approaches  to  system  security  are  most  often  piecemeal  with  little  or  no  support 
for  guiding  what  system  security  requirements  must  address  across  different  system¬ 
processing  elements  and  data  levels,  and  how  those  can  be  manifest  during  the  design, 
building,  and  deployment  of  OA  software  systems.  We  present  a  framework  that  organizes 
OA  system  security  elements  and  mechanisms  in  forms  that  can  be  aligned  with  different 
stages  of  acquisition  spanning  system  design,  building,  and  run-time  deployment,  as  well  as 
system  evolution.  We  provide  a  case  study  to  show  our  scheme  and  how  it  can  be  applied  to 
common  enterprise  systems. 

Introduction 

We  seek  to  research,  develop,  and  refine  new  concepts,  techniques,  and  tools  for 
continuously  assuring  the  security  of  large-scale,  open  architecture  (OA)  software  systems  composed 
from  software  components  that  include  proprietary/closed  source  software  (CSS)  and  open  source 
software  (OSS).  Federal  government  acquisition  policy,  as  well  as  many  leading  enterprise  IT 
centers,  now  encourage  the  use  of  CSS  and  OSS,  and  thus  OA,  in  the  development,  deployment, 
and  evolution  of  complex,  software-intensive  systems. 

We  seek  to  prototype  and  demonstrate  a  new  innovative  approach  and  supporting 
technology  that  can  develop  new  principles  for  correctness  and  security  properties  for  OA  systems. 
This  includes  developing  basic  principles  to  determine  the  security  and  performance  properties  of 
software  systems,  the  conditions  under  which  these  properties  hold,  and  the  methods  used  to  prove 
these  properties  of  interest  for  systems.  Of  particular  interest  are  networked  OA  software  systems 
that  are  adapted  or  that  evolve  to  dynamic  conditions  and  threats  during  their  development, 
deployment,  and  usage,  including  those  that  may  rely  on  new  technologies  like  OA  mobile  devices 
(Smalley,  2012;  “Security  Technical  Information  Guide,”  n.d.)  or  other  IT  systems  relying  on  open 
source  technologies  (Department  of  Defense  [DoD],  2010;  Garcia,  2010;  Gizzi,  2011;  Navy,  2010).  In 
particular,  such  study  may  be  of  value  to  securing  new  cyber  warfare  technologies  (DoD,  201 1 ; 
Scacchi,  Brown,  &  Nies,  201 1 ).  Our  efforts  may  also  lead  to  fundamental  advancements  for  secure 
information  sharing  between  information  producers  and  consumers  in  order  to  realize  more  secure 
information  management,  sharing,  and  interaction. 
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Challenges  of  Securing  Systems  with  Open  Architectures 

Coordinated  international  attacks  on  vulnerable  software-intensive  systems  that  are 
of  high  value  and  on  control  complex  systems  are  becoming  ever  more  apparent.  As  the 
StuxNet  case  demonstrates,  security  threats  to  software  systems  are  multi-valent,  multi¬ 
modal,  and  distributed  across  independently  developed  software  system  components 
(Stuxnet,  2011).  Similarly,  it  is  now  clear  that  physically  isolated/confined  systems  are 
vulnerable  to  external  security  attacks  via  portable  storage  devices  like  USB  drives,  modified 
end-user  devices  (e.g.,  keyboards,  mice;  “Attack  of  the  Computer  Mouse,”  2011),  and  social 
engineering  techniques  (Sawyers,  2011).  This  requires  new  security  measures  and  policies 
necessary  to  defend  such  systems  through  new  threat  prevention  and  detection  methods, 
as  well  as  appropriate  response  mechanisms.  Thus,  what  makes  a  system  or  system 
architecture  secure  changes  over  time,  as  new  threats  emerge  and  as  systems  evolve  to 
meet  new  functional  requirements.  Consequently,  there  is  need  for  an  approach  to 
continuously  assure  the  security  of  complex,  evolving  OA  systems  in  ways  that  are  practical 
and  scalable  yet  robust,  tractable,  and  adaptable. 

However,  the  best  practices  for  developing  OA  systems  whose  components  may  be 
subject  to  differing  security  requirements  (e.g.,  security  rights  and  obligations)  are  unclear. 
Such  practices  are  yet  to  be  identified.  This  puts  IT  centers,  system  integrators,  and  service 
providers  at  a  disadvantage  when  seeking  to  develop  new  software-intensive  systems 
whose  costs  may  be  lower  due  to  the  integration  of  mature  OSS  components  that  are 
interfaced  to  pre-existing  or  new  CSS  components.  OA  systems  thus  present  new 
challenges  for  assuring  software  system  security. 

Software  systems  security  mechanisms  for  enabling  security  requirements  or  policies 
are  often  employed  on  an  ad  hoc  basis,  because  there  are  not  convenient  or  interactive 
tools  or  formal  techniques  for  specifying  the  security  requirements  of  an  OA  system  or  its 
components.  Instead,  what  is  available  are  disjoint  mechanisms  for  implementing  individual 
system  security  features  (Loscocco  et  al.,  1998;  Spencer  et  al. ,  1999),  such  as 

•  mandatory  access  control  lists  and  firewalls; 

•  multi-level  security; 

•  authentication  (including  certificate  authority  and  passwords); 

•  cryptographic  support  (including  public  key  certificates); 

•  encapsulation  (including  virtualization  and  hidden  versus  public  APIs),  hardware 
confinement  (memory,  storage,  and  external  device  [port]  isolation;  Sun,  Wang, 
Zhang,  &  Stavrou,  2012),  and  type  enforcement  capabilities; 

•  secure  programming  practices  (including  secure  coding  standards,  data  type, 
and  value  range  checking;  Seacord,  2008); 

•  data  content  or  control  signal  flow  logging/auditing; 

•  honey-pots  and  traps; 

•  security  technical  information  guides  for  configuring  the  security  parameters  for 
applications  (“Security  Technical,”  2011)  and  operating  systems  (Smalley,  2012); 
and 

•  functionally  equivalent  but  diverse  multi-variant  software  executables  (Franz, 
2010;  Salamat,  Jackson,  Wagner,  Wimmer,  &  Franz,  2011). 

But  there  is  a  gap  between  these  mechanisms  and  any  concept  of  a  comprehensive 
security  policy,  whether  for  a  system  or  for  any  of  its  components,  and  no  obvious  way  to 
integrate  and  evaluate  them  as  a  group.  Similarly,  it  is  unclear  what  relationships  arise  or 
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are  in  place  among  these  different  security  mechanisms.  Further,  what  guidance  is  needed 
regarding  which  security  mechanism  to  use  where,  when,  why,  and  how,  and  how  is  their 
usage  updated  or  configured  as  extant  system  security  policy  evolves?  The  mechanisms 
are  also  mostly  software  implementation  choices  rather  than  system  architectural  choices; 
no  system-specific  framework  (like  an  architecture)  exists  in  which  they  can  be  pulled 
together  in  patterns  that  can  be  designed  to  meet  specific  security  policies  and  goals.  But  in 
an  OA  system,  it  may  be  unclear  or  unlikely  that  system  integrators  will  find  mature  OSS  or 
CSS  components  that  supply  all  of  the  system  security  features  that  the  integrator  or  the 
customer  requires  on  a  timely,  cost-effective  basis. 

Next,  OA  systems  evolve  through  more  pathways  than  traditional  systems: 

•  individual  components  evolve  through  update  revisions  (e.g.,  security  patches) 
made  by  the  component’s  developers; 

•  individual  components  are  updated  with  new,  functionally  enhanced  versions 
from  outside  providers; 

•  individual  components  are  replaced  by  different  components  from  other  sources; 

•  component  interfaces  evolve,  either  due  to  the  system  developers  or  outside 
sources; 

•  system  architecture  and  configuration  evolve  as  the  developers  adapt  them  to 
address  new  functional  requirements; 

•  system  functional  and  security  requirements  evolve,  either  due  to  the  system 
developers,  recognized  gaps,  or  outside  stakeholders;  and 

•  system  security  policies,  mechanisms,  security  components,  and  system 
configuration  parameter  settings  also  change  overtime. 

These  additional  evolution  paths  are  tied  to  the  benefits  of  using  OA  systems  with 
OSS  components,  but  they  also  present  new  challenges  for  security.  OA  systems  are 
continually  evolving,  and  in  our  view  this  fact  is  fundamentally  unaddressed  by  prior  work  in 
security. 

Beyond  these  issues,  we  must  consider  the  following:  How  should  customers  specify 
what  security  system  features  they  want  their  delivered  systems  to  support?  How  can  the 
history  of  security  failures  (vulnerabilities),  faults  (exploits),  possible  cyber-warfare  attacks 
(threats),  and  possible  responses  (updating  system  configuration  with  new  elements  that 
resist  new  threats,  close  new  vulnerability,  and  prevent  newly  discovered  exploits)  guide  the 
evolution  of  approaches  for  developing  secure  OA  systems?  How  can  answers  to  questions 
like  these  help  formulate  a  technological  innovation  element  of  the  DoD  strategy  for 
operating  in  cyberspace  (DoD,  2011)?  Questions  like  this  remain  unresolved  at  present. 

Verification  of  the  usage  of  security  mechanisms  in  software  systems  is  unclear  and 
often  focused  either  at  the  whole  system  (macro)  level,  or  at  the  program  function  or  coding 
(micro)  level,  but  generally  not  at  the  architectural  component  and  interconnection  (meso) 
level,  and  not  for  combinations  and  alternative  configurations  of  CSS  and  OSS  components 
with  different  security  histories.  We  believe  that  there  is  a  new  or  under-explored  opportunity 
to  address  security  requirements  at  the  architectural  level. 

As  such,  we  see  the  following  basic  challenges  in  assuring  OA  system  security: 

•  how  to  verify  the  security  of  OA  system  designs  throughout  system  development, 
deployment,  and  post-deployment  support;  and 
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•  how  to  validate  the  effectiveness  of  OA  system  security  measures  and  feed 
evolving  knowledge  of  vulnerabilities  and  exploits  back  into  the  ongoing 
development  (continuous  evolution)  stream  for  existing  and  planned  systems  in 
an  operational,  testable  form  that  system  designers  can  use  and  program 
managers  can  assess. 

Similarly,  we  see  the  following  basic  challenges  in  assuring  security  of  OA  software 
systems: 

•  how  best  to  develop  complex  OA  systems  whose  OSS  or  CSS  system 
components  may  originally  come  from  trusted  sources  but  in  which  these 
components,  the  architectural  configuration,  and  security  requirements  are 
subject  to  multiple  sources  of  adaptation  and  evolution; 

•  how  to  go  beyond  “many  eyes”  (a  large  number  of  skilled  reviewers)  to  establish 
a  scalable  basis  for  automated  or  semi-automated  verification  of  software  system 
security  properties  as  the  system  continually  evolves; 

•  how  best  to  achieve  continuous  software  system  security  assurance  as  a  system 
is  adapted  and  evolved  to  address  new  security  requirements  and  technology 
progress; 

•  how  best  to  protect  OA  systems  through  biologically  inspired  natural  defenses 
that  provide  adaptive  and  resilient  mechanisms,  including  agile  response, 
isolation,  and  fail-soft  recovery  to  immediate  attacks,  as  well  as  adaptation  via 
dynamic  reconfiguration,  multi-version  mechanisms,  (artificial)  ecological 
diversity  responses  to  sustained  vulnerabilities  or  threats  (Shrobe,  201 1 );  and 

•  how  to  create  reference  models  and  security  policy  requirements  that  articulate 
security  scenarios  appropriate  for  oversight  during  system  acquisition,  as  well  as 
during  system  design,  implementation,  deployment,  and  beyond. 

Securing  Software  Systems 

The  key  ideas  in  our  approach  to  develop  and  demonstrate  a  new  solution  to  the 
challenges  is  to  specify  verifiable  security  requirements  of  OA  systems  using  formalized 
“security  licenses”  (Scacchi  &  Alspaugh,  2011)  and  to  use  an  explicit,  evolvable  software 
architecture  to  mediate  and  carry  the  paths  of  interactions  among  them.  Security  licenses 
must  specify  the  security  requirements  and  access/update  rights  and  obligations  within  an 
OA  system,  its  CSS  and  OSS  components,  and  their  interconnections  (e.g.,  APIs, 
databases,  shared  files,  and  communication  protocols)  that  defend  against  threats  and 
enable  appropriate  responses  to  attacks  or  suspicious/anomalous  system  behaviors. 
Subsequently,  the  goal  of  our  approach  is  to  articulate  and  refine  the  ways  and  means  for 
expressing  and  verifying  that  the  security  requirements  of  OA  system  components  match  up 
appropriately  and  together  support  the  security  requirements  of  the  entire  OA  system  at 
architectural  design-time  while  enabling  the  automated  verification  of  system 
builds/compositions  and  deployable,  as  well  as  of  executable  run-time  versions  of  the 
system. 

Software  licenses  represent  a  collection  of  rights  and  obligations  for  what  can  or 
cannot  be  done  with  a  licensed  software  component.  Licenses  can  thus  denote  both 
functional  and  non-functional  requirements  that  apply  to  software  systems  or  system 
components  during  their  development  and  deployment.  But  rights  and  obligations  are  not 
limited  to  concerns  or  constraints  applicable  only  to  software  as  IP.  Instead,  they  can  be 
written  in  ways  that  stipulate  functional  or  non-functional  requirements  of  different  kinds. 
Consider,  for  example,  that  desired  or  necessary  software  system  security  properties  can 
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also  be  expressed  as  rights  and  obligations  addressing  system  confidentiality,  integrity, 
accountability,  system  availability,  and  assurance.  This  kind  of  approach  provides  new 
principles  of  correctness  for  software  IP  requirements  (Breaux  &  Anton,  2005,  2008). 

Traditionally,  developing  robust  specifications  for  non-functional  software  system 
security  properties  in  natural  language  often  produces  specifications  that  are  ambiguous, 
misleading,  inconsistent  across  system  components,  and  lacking  sufficient  details  (Yau  & 
Chen,  2006).  Using  a  semantic  model  and  logic  to  formally  specify  the  rights  and  obligations 
required  for  a  software  system  or  component  to  be  secure  (Breaux  &  Anton,  2005,  2008; 

Yau  &  Chen,  2006)  means  that  it  may  be  possible  to  develop  both  a  “security  architecture” 
notation  and  model  specification  that  associates  given  security  rights  and  obligations  across 
a  software  system,  or  system  of  systems.  Similarly,  it  suggests  the  possibility  of  developing 
computational  tools  or  interactive  architecture  development  environments  that  can  be  used 
to  specify,  model,  and  analyze  a  software  system’s  security  architecture  at  different  times  in 
its  development — design-time,  build-time,  and  run-time.  We  have  already  demonstrated  how 
such  an  approach  can  work  when  limiting  attention  to  IP  rights  and  obligations. 

The  approach  we  have  been  developing  for  the  past  few  years  for  modeling  and 
analyzing  software  system  IP  license  architectures  for  OA  systems  (Alspaugh,  Asuncion,  & 
Scacchi,  2009;  Alspaugh,  Scacchi,  &  Asuncion,  2010;  Scacchi  &  Alspaugh,  2008)  may 
therefore  be  extendable  to  also  address  OA  systems  with  heterogeneous  software  security 
license  rights  and  obligations  (Scacchi  &  Alspaugh,  2011).  Furthermore,  the  idea  of  common 
or  reusable  software  security  licenses  may  be  analogous  to  the  reusable  security 
requirements  templates  Firesmith  (2004)  proposed  at  the  Software  Engineering  Institute. 
Such  security  requirement  templates  may  simplify  and  guide  the  efforts  of  customers  (or 
contracting  officers)  to  more  readily  specify  workable  requirements  that  can  be  readily 
verified  through  system  development,  deployment,  and  post-deployment  support. 

Security  licenses  can  be  specified,  modeled,  and  analyzed  continuously  from  initial 
system  architectural  design  through  post-deployment  support  and  system  evolution,  with 
key  points  for  security  license  analysis  occurring  at  design-time,  build/linking-time,  and 
deployment/run-time.  Such  security  licenses  can  be  stated  both  (a)  informally,  using 
restricted  natural  language  for  human  readability,  authorship,  and  description  of  non¬ 
functional  security  requirements;  as  well  as  (b)  formally,  specifying  functional  security 
requirements  in  a  computer  processable  form  using  a  logic-based  scheme  and  modeling 
notation,  with  automated  production  of  (a)  from  (b)  and  automated  architecture-mediated 
inferences  using  (b).  Analysis  of  a  system/s  security  requirements  can  therefore  be 
integrated  into  the  software  architecture  tool  used  to  express  and  evolve  the  architecture  so 
that  the  analysis  evolves  automatically  in  parallel  with  the  architecture. 

In  general  terms,  a  security  license  is  analogous  to  a  software  copyright  license  such 
as  a  general  public  license  (GPL;  GNU,  2007).  Software  licenses  consist  of  intellectual 
property  (IP)  rights  granted  by  the  license,  and  corresponding  license  obligations  needed  to 
obtain  the  rights.  Our  innovation  is  to  similarly  specify  the  security  obligations  and  rights  of 
OA  system  components  using  elements  found  in  known  security  capabilities,  which  we  can 
then  model,  analyze,  and  support  throughout  the  system’s  development  and  evolution,  and 
use  to  guide  system  design  and  instantiation.  Our  initial  investigation  of  security  licenses 
(Scacchi  &  Alspaugh,  2011)  has  identified  rights  and  obligations,  such  as 

•  the  obligation  for  a  user  to  verify  his/her  authority  to  see  compartment  T  by 
password  or  other  specified  authentication  process; 

•  the  obligation  for  a  specific  component  to  have  been  vetted  for  the  capability  to 
read  and  update  data  in  compartment  T; 
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•  the  obligation  for  all  components  connected  to  specified  component  C  to  grant  it 
the  capability  to  read  and  update  data  in  compartment  T; 

•  the  obligation  to  reconfigure  a  system  in  response  to  detected  threats  when  given 
the  right  to  select  and  include  different  component  versions  or  executable 
component  variants; 

•  the  right  to  read  and  update  data  in  compartment  T  using  the  licensed 
component; 

•  the  right  to  replace  specified  component  C  with  some  other  component; 

•  the  right  to  add  or  update  specified  component  Dina  specified  configuration; 

•  the  right  to  add,  update,  or  remove  a  security  mechanism;  and 

•  the  right  to  update  security  license  L. 

Further,  formally  specified  OA  security  licenses  are  verifiable,  as  well  as  grounded  in 
functional  and  testable  system  security  capabilities. 

The  security  reasoning  chains  among  the  security  licenses  are  mediated  by  the 
system  architecture  and  evolve  automatically  with  it,  much  like  they  can  for  IP  licenses 
(Alspaugh  et  al. ,  2009;  Alspaugh  et  al. ,  201 1 ;  Alspaugh  et  al. ,  201 0).  Each  kind  of  security 
license  details  how  its  obligations  are  propagated  architecturally  to  other  system 
components.  The  results  of  this  propagation,  coupled  with  automated  identification  of  gaps, 
conflicts,  and  subsumptions,  are  communicated  to  analysts  as  architecturally  organized 
arguments  supporting  the  existence  of  the  identified  issues.  The  arguments  provide  context- 
appropriate  guidance  in  terms  of  the  system  architecture  and  the  security  licenses  of  the 
components  involved  for  resolution  of  security  problems  through  the  evolution  of  the  system 
design. 

Our  approach  neither  assumes  nor  proves  that  individual  elements  of  an  OA  system 
are  secure  but  instead  seeks  to  determine  what  security  rights  and  obligations  are  in  effect 
at  any  time  for  the  overall  system  architecture  as  a  function  of  the  security  rights  and 
obligations  of  its  components.  This  means  that  it  is  possible  to  configure  a  secure  OA 
system  whose  components  may  be  insecure,  or  not  equally  secure.  Our  approach  also 
supports  determination  of  where  or  how  OA  system  security  rights  or  obligations  may  be  in 
conflict,  mismatch,  or  subsume  one  another  as  individual  system  components  or  connectors 
are  adapted  to  evolve  over  time.  As  an  organization’s  security  policies  (i.e. ,  their  security 
requirements)  evolve  and  adapt,  the  OA  system’s  security  rights  and  obligations  are  evolved 
to  match  and  satisfy  them,  as  long  as  all  security  requirements  can  be  expressed  through 
description  logic  relationships  among  them. 

Security  rights  and  obligations  are  characterized  in  terms  of  enterprise  security 
policies  and  goals;  within  that  closed  world,  our  approach  enables  specification  of  the 
security  properties  that  an  open  system  architecture  must  match  or  satisfy.  These  security 
requirements  also  direct  acquisition  program  managers  and  architecture  analysts  attention 
to  problem  areas  with  greatest  impact  on  system  security.  Where  our  approach  identifies  a 
conflict  or  mismatch,  it  indicates  an  actual,  open-world  weakness  in  the  security  of  the  OA 
system  under  analysis.  The  chain  of  reasoning  is  architecture-mediated,  with  its  units 
defined  piecewise  in  each  component's  security  license  and  evolving  continuously  as  the 
system  architecture,  configuration,  and  security  requirements  evolve.  As  new  kinds  or  types 
of  vulnerability,  threats,  or  exploits  emerge,  as  well  as  new  categories  of  effective  responses 
and  emerging  alternative  security  mechanisms,  we  seek  to  elaborate  and  demonstrate  that 
this  approach  can  continuously  accommodate  the  specification  and  analysis  of  changing 
security  requirements. 
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Product  Lines:  Alternatives,  Versions,  and  Variants  of  OA  Elements 

In  producing  a  secure  OA  system  in  a  software  product  line,  there  are  several  levels 
of  variation  available  for  producing  artificial  diversity  among  equivalent  instances  and  for 
selecting  and  evolving  in  the  face  of  threats. 

At  the  highest  level  of  granularity,  a  system  developer  or  integrator  can  choose 
among  alternative  producers  of  similar  components,  services,  and  platforms  (Sun  et  al., 
2012).  For  example,  we  can  find  functionally  similar  alternatives  from  software  (component) 
producers  of  Web  browsers  like  Mozilla  (Firefox,  Camino,  Sea  Monkey)  versus  Google 
(Chrome)  versus  Microsoft  (Internet  Explorer),  versus  others.  Similarly,  for  word  processors, 
we  find  alternatives  including  Microsoft  (Word)  versus  abisoft.com  (AbiWord)  versus  Google 
(Google  Docs,  which  is  a  remote  Web  service  rather  than  a  component),  versus  others. 
Likewise,  for  e-mail  and  calendar  applications,  we  find  alternatives  like  Microsoft  Outlook, 
Gnome  Evolution,  Google  Mail,  and  Google  Calendar,  among  others.  For  operating 
systems,  we  find  Red  Hat  Enterprise  Linux,  Microsoft  Windows,  Apple  OSX,  and  Google 
Android,  among  others.  Finally,  note  that  some  producers  produce  more  than  one 
alternative  of  the  same  kind  of  component  or  service,  such  as  Mozilla’s  Web  browsers 
(Firefox,  Camino,  SeaMonkey),  so  that  a  choice  among  those  particular  components  does 
not  result  in  a  change  of  producers. 

Functionally  similar  components  and  services  may  not  be  exactly  interchangeable, 
unless  their  interfaces  are  similar  or  identical.  As  such,  it  may  be  necessary  to  modify,  for 
example,  OA  system  topology  or  replace  connector  types,  and  other  architectural  measures 
may  be  necessary  to  change  from  one  producer  to  another,  depending  on  the  functionality 
needed  to  satisfy  functional  requirements.  However,  in  general,  the  overall  functionality 
provided  by  the  system  remains  substantially  the  same;  but  now  the  diversity  among 
alternative  system  instances  is  the  greatest:  not  only  is  the  component,  service,  or  platform 
distinct  between  two  instances,  but  its  architectural  connections  in  the  system  will  also  be 
distinct,  as  will  be  the  software  development  process  and  organization  that  produced  it;  so 
the  chances  of  a  common  vulnerability  are  greatly  minimized.  Subsequently,  when 
functionally  similar  components,  connectors,  or  configurations  exist,  such  that  equivalent 
alternatives,  versions,  or  variants  may  be  substituted  for  one  another,  then  we  have  a  strong 
relationship  among  these  OA  system  elements  that  is  called  a  product  family 
(Narayanaswamy  &  Scacchi,  1987;  Bosch,  2006)  or  a  product  line  (Clements  &  Northrop, 
2001). 

As  described  previously,  a  shift  from  one  alternative  to  another  ordinarily  requires  a 
change  in  architecture,  software  connectors,  and  other  measures.  Changes  between  some 
alternatives  will  also  produce  a  change  of  producers,  while  others  will  not.  However,  when 
components  or  connectors  provide  alternative  implementations  of  the  functionality  they 
provide,  then  these  are  designated  as  versions.  For  example,  most  Linux  operating  systems 
support  multiple  file  systems  for  data  storage,  though  developers  or  integrators  select  their 
preferred  file  system  for  inclusion  at  either  design-time  or  build-time.  Similarly,  for 
connectors  to  remote  Web  servers,  developers  or  integrators  may  specify  unencrypted  (e.g., 
HTTP)  or  encrypted  (e.g.,  HTTPS)  data  communication  protocols  for  use  in  a  Web-based 
enterprise  system.  Next,  at  the  OA  system  configuration  level,  selection  of  alternative 
components  or  connectors,  or  of  different  versions  of  components  or  connectors,  result  in 
different  overall  system  versions  that  conform  to  a  system  product  line.  Further,  recent 
advances  in  source  code  compilation  now  allow  for  creation  of  functionally  identical  variants 
of  software  components,  though  each  variant  has  a  different  run-time  image  in  the 
computer,  through  code  randomization  techniques  (Franz,  2010;  SJWWF1 1).  Last,  software 
product  lines  can  be  bound  to  a  network  of  software  producers,  system  integrators,  and 


ACQUISITION  RESEARCH  PROGRAM: 
CREATING  SYNERGY  FOR  INFORMED  CHANGE 


-  171  - 


system  users/consumers  through  a  software  ecosystem  (Bosch,  2009),  such  that  secure 
systems  can  be  realized  through  composition  or  configuration  at  the  software  ecosystem 
level  (SA12).  Consequently,  we  now  have  a  complete  and  robust  basis  for  specifying  OA 
systems  that  can  include  components,  connectors,  or  application  systems  from  alternative 
producers,  or  with  different  versions  or  variants  included.  This  is  now  our  basis  for  moving 
forward  to  address  the  challenges  of  creating  secure  OA  systems  through  secured  software 
product  lines. 

Given  the  basis  for  software  product  lines  for  OA  systems,  we  now  address  how  to 
frame  and  align  software  system  architectures  with  software  security  mechanisms.  We  use 
the  following  scheme  to  address  this,  as  shown  in  Table  1 . 

Table  1.  Different  System  Security  Elements  Whose  Rights  and  Obligations 
Depend  on  Capabilities  Supported  by  Lower  Level  Elements 


Security  policies 

Developers,  system  integrators  and  users 

Persistent  data 

System  configurations 

Ephemeral  data 

Components 

Connectors 

User  I/O  data 

Platforms 

System  security  policies  provide  the  overall  context  for  what  kinds  of  security 
mechanisms  or  capabilities  (e.g.,  mandatory  role-based  data  access  control)  that  a 
particular  systems  requires.  The  requirements  must  be  realized  through  multiple  levels  of 
system  composition  that  span  a  processing  space  from  people  to  processing  platforms,  and 
through  data/content  space  that  is  processed  during  system  usage/operation. 

Aligning  system  security  elements  with  security  mechanisms  gives  rise  to  the 
following  associations: 

Platform — base  technological  elements  that  constitute  the  computer  environment 

that  hosts  the  target  system: 

•  hardware :  specifies  hardware  confinement  constraints  needed  to  securely 
operate  the  software  system  configuration,  potentially  to  address  memory, 
storage,  and  external  device  port  isolation  (see  SecureSwitch  [Sun  et  al. ,  2012)]). 
Hardware  may  be  configured  as  an  embedded  processor,  mobile  computer  (e.g., 
smartphone  or  tablet),  personal  computer,  multi-processor  computation  server,  or 
multi-server  data  center; 

•  virtual  machine :  a  software  layer  that  can  isolate  and  confine  the  operating 
system,  component  applications,  or  application  services  from  direct  control  of 
system  hardware,  network  operations,  or  operating  system  processes.  OSs, 
software  systems,  components,  or  connectors  can  each  run  within  their  own 
virtual  machine,  in  alternative  configurations,  as  long  as  they  are  completely 
confined  at  a  higher  level  of  system  security  and  do  not  overlap  virtual  machine 
boundaries  (Spencer  et  al.,  1999;  Smalley,  2012); 
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•  network :  message  filtering  and  access  control  firewalls  for  data/control  flows  that 
move  across  external  hardware  system  security  boundaries;  and 

•  operating  systems :  mandatory  access  control  (Loscocco  et  al. ,  1998;  Spencer  et 
al. ,  1999),  capability  type  enforcement  (Smalley,  2012),  OS  configuration 
parameters  (“Security  Technical,”  n.d.),  and  run-time  audit  logs,  all  currently 
coded  and  managed  by  system  integrators/administrators. 

Connectors — software  mechanisms  that  implement  secure  communication 
mechanisms  within  and  across  system  boundaries.  Connectors  enable  security 
mechanisms  providing 

•  data  cryptography  (encryption/decryption)  before/after  data  transfer; 

•  component-connector-specific  firewalls  that  can  be  implemented  via  (pre¬ 
conditions)  constraints  on  in-bound  data  flow  and  plug-in/helper  application 
invocation,  or  on  out-bound  data  flow  and  external  program  invocations  (post¬ 
conditions);  and 

•  multi-version  connector  configurations  between  components  that  allow  for 
artificial  diversity  and  dynamic  reconfiguration  potential  through  functionally 
similar  versions. 

Components — software  mechanisms  that  implement  application  functionality 
required  for  the  targeted  system  to  operate  as  intended.  Components  enable  security 
mechanisms  providing 

•  access/usage  authentication  control  obligations  (e.g.,  login  with  authorized 
identification  and  password)  for  which  people  in  what  roles  (e.g.,  developer, 
system  integrator,  system  administrator,  system  user)  have  the  specified  set  of 
rights  to  view/update  data,  data  control  flow  invocations,  or  external  program 
invocations; 

•  encapsulate  components  as  services  within  virtual  machines  to  confine  potential 
exploits  while  mitigating  their  propagation; 

•  alternative  versions  that  increase  artificial  diversity  and  enable  dynamic 
replacement  with  functionally  similar  alternatives; 

•  multiple  versions  that  allow  for  changes  in  vulnerability  space,  including 
concurrent  versions  with  replicated  input  data,  but  different  out  data  connector 
(routing)  configurations;  and 

•  multiple  variants  that  reduce  vulnerability  to  component  version  attacks. 

System  configuration — the  composition  and  interrelationship  of  components  and 
connectors  that  together  realize  the  system  architecture  at  design-time,  build-time,  or 
run-time.  System  configuration  (or  composition  [Bo06])  enables  security  by  providing 

•  the  ability  to  host  multiple  (one  or  more)  alternative,  version,  or  variant  system 
configurations  on  one  or  more  processors  (either  single-core  [Sun  et  al.,  2012], 
multi-core,  multi-blade,  or  multi-site)  that  can  be  dynamically  selected  in 
response  to  security  policy  directives  or  in  response  to  detected  threats; 

•  the  ability  to  host  concurrently  running  multiple  (one  or  more)  alternative,  version, 
or  variant  system  configurations  on  one  or  more  processors  (either  multi-core, 
multi-blade,  or  multi-site)  that  can  be  dynamically  selected  in  response  to  security 
policy  directives  or  in  response  to  detected  threats;  and 
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•  the  ability  to  (formally)  specify  system  configuration  as  an  open  architecture  at 
design-time,  build-time,  and  deployment  run-time,  along  with  automated  tools 
that  can  verify  the  consistency,  completeness,  and  traceability. 

Developers,  system  integrators,  and  users — denote  the  people  authorized  and 
trusted  to  work  on  or  with  the  configured  systems  or  their  elements  over  time, 
depending  on  their  externally  assigned  role(s): 

•  developers  should  employ  software  development  environments,  tools,  or 
processes  that  reinforce  security-safe  software  coding  practices  of  components 
or  connectors  they  implement  as  products  (Seacord,  2008); 

•  developers  should  produce  multiple,  unique,  executable  variants  of  the 
components  or  connectors  they  produce  and  distribute; 

•  system  integrators  design  OA  system  architecture; 

•  system  integrators  build  OA  system  configurations  that  select  from  one  or  more 
component  or  connector  alternatives,  versions,  and  variants; 

•  system  integrators  deploy  one  or  more  run-time  system  configuration  variants 
that  can  be  readily  installed  and  appropriate  parameters  entered  by  system 
administrators  or  end  users; 

•  system  integrators  or  system  administrators,  or  automated  mechanisms  under 
their  control  must  be  able  to  monitor  and  access  system  execution  audit  logs,  to 
determine  if  threats  or  anomalous  system  behaviors  are  detected,  and  to 
dynamically  reconfigure  system  configuration  or  security  parameters  in  order  to 
move  the  executable  system  into  a  more  trusted  operational  state; 

•  users  must  be  provided  with  online  identifiers  or  identification  methods  that 
enable  them  to  access  security  controlled  systems  via  one  or  more  alternative 
authentication  mechanisms  in  place. 

In  parallel  with  these  processing  security  spaces  are  data  security  spaces: 

User  I/O  data — data  that  may  exist  only  as  it  passes  across  communication 
channels.  Examples  are  keystrokes  and  mouse  movements  communicated  from  a 
keyboard  or  mouse  to  a  processor,  voice  data  from  microphones  and  to  speakers, 
Wi-Fi  packets,  and  so  forth.  This  data  may  be  discarded  or  incorporated  into 
ephemeral  data. 

Ephemeral  data — data  that  exists  in  memory  for  a  brief  time  before  being  either 
discarded  or  incorporated  into  persistent  data.  Examples  are  Web  forms  that  have 
been  filled  out  but  not  submitted,  and  data  in  various  sorts  of  hardware  buffers. 

Persistent  data — data  that  exists  for  a  substantial  time  on  local  disks  or  solid-state 
storage  devices,  USB  memory  sticks,  DVD-ROM,  or  server  storage. 

Security  policies — provide  overall  guidance  and  requirements  for  what  security 
mechanisms  and  regimes  are  to  be  designed,  implemented,  and  satisfied  during  the 
deployment,  operation,  and  evolution  of  a  specified  system.  Security  policies 

•  should  provide  non-functional  requirements  regarding  the  membership,  structure, 
and  behavioral  specifications  of  each  of  the  proceeding  categories  of  security 
elements  at  minimum,  or  further  specification  of  security  sub-elements  within 
each  category,  as  per  the  security  exposure  of  the  system  being  addressed; 
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o  non-functional  requirements  may  only  specify  rights  provided  when 
corresponding  obligations  are  fulfilled  that  cannot  be  automated  or 
verified  in  lower  level  security  elements; 

o  non-functional  requirements  should  be  expressible  in  human-readable 
and  computer-processable  forms  within  the  system  security  policy 
license;  and 

•  must  provide  functional  requirements  regarding  the  membership,  structure,  and 
behavioral  specifications  of  each  of  the  proceeding  categories  of  security 
elements  at  minimum,  or  further  specification  of  security  sub-elements  within 
each  category,  as  per  the  security  exposure  of  the  system  being  addressed; 

o  functional  requirements  are  those  that  can  be  formalized,  automated,  and 
verified  by  corresponding  automated  mechanisms  available  at  lower  level 
security  elements; 

o  functional  requirements  may  only  specify  rights  provided  when 

corresponding  obligations  are  fulfilled  that  must  be  automated  or  verified 
in  lower  level  security  elements;  and 

o  functional  requirements  should  be  expressible  in  human-readable  and 
computer-processable  forms  within  the  system  security  policy  license. 

The  case  study  that  follows  describes  where  these  different  system  security 
elements  appear  in  forms  that  can  be  available  for  review  by  authorized  program  acquisition 
personnel. 


Case  Study  of  a  Secure  Product  Line  for  an  Enterprise  System 

Let  us  consider  what  needs  to  be  specified  during  the  acquisition  of  an  enterprise 
system  that  incorporates  common  office  productivity  applications  that  run  on  a  personal 
computer  networked  to  remote  servers.  Such  a  system  can  include  a  Web  browser,  word 
processor,  e-mail,  and  calendaring  applications  that  are  configured  to  operate  on  a  personal 
computer,  where  the  PC’s  operating  system,  Web  browser,  and  other  applications  need  to 
be  configured  to  access  remote  data/Web  content  servers.  Figure  1  shows  part  of  the 
system  ecosystem  of  software  producers  and  the  components  they  can  provide  for  our 
enterprise  system. 
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Figure  1.  A  Partial  View  of  a  Software  Ecosystem  of  Producers  and  the  Software 

Components  for  an  Enterprise  System  They  Produce 

Figure  2  shows  the  design-time  architecture  of  such  an  enterprise  system.  What 
might  a  secure  product  line  for  a  system  like  this  involve,  and  how  might  it  provide  benefits 
and  security  qualities  to  be  specified  for  design-time,  build-time,  and  run-time?  How  can  its 
OA  and  product-line  characteristics  contribute  to  security  throughout  the  acquisition  system 
life-cycle? 
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Figure  2.  A  Design-Time  Reference  Model  of  an  OA  System  That  Accommodates 

Multiple  Alternative  System  Configurations 


We  envision  an  approach  in  which  non-functional  requirements,  such  as  security, 
reliability,  and  evolvability  requirements  at  acquisition  time  are  elaborated  at  design-  and 
build-times  by  specific  functional  requirements  that  explain  how  and  to  what  degree  the  non¬ 
functional  requirements  are  going  to  be  satisfied  at  run-time.  Analogous  to  our  previous 
work  with  IP  licensing,  we  envision  that  these  requirements  are  structured  in  the  same 
logical  forms  as  IP  licenses  (with  specific  rights  that  are  obtained  only  by  fulfilling  specific 
obligations)  and  managed  through  the  architecture  by  the  same  approach  of  calculating 
which  obligations  are  satisfiable,  in  what  way,  and  as  a  result  what  rights  are  available 
(Alspaugh  et  al. ,  2009;  Alspaugh  et  al. ,  201 0;  Scacchi  &  Alspaugh,  201 1 ). 
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Figure  3.  A  View  of  an  OA  Software  Ecosystem  That  Provides  Alternative, 

Functionally  Similar  Components  Compatible  With  the  Reference  Design- 

Time  Architecture 
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Figure  3  illustrates  a  possible  OA  software  ecosystem  for  this  product  line.  Here,  a 
number  of  possible  producers  and  alternative  components  have  been  placed  into  play,  and 
four  specific  instance  architectures  (produced  in  four  specific  ecosystems)  have  been 
sketched.  With  appropriate  architectural  topologies,  and  appropriate  shim  components  and 
connectors  inserted  between  the  major  components,  each  of  these  four  instance 
architectures  can  support  the  same  functionality.  It  is  also  possible  to  achieve  different 
nonfunctional  qualities,  including  security  qualities  through  the  four  choices,  for  example,  by 
requiring  that  OS  be  an  appropriate  security-enhanced  version  of  Linux,  or  by  requiring  that 
the  network  protocol  connector  be  HTTPS. 


Within  the  overall  ecosystem  of  Figure  3,  Figure  4  shows  one  possible  instance 
ecosystem  involving  specific  producers  (Mozilla,  abisource.org,  gnome.org,  Red  Hat)  and 
specific  alternatives  (Firefox,  AbiWord,  Evolution,  Fedora). 


Firefox 

Opera 

AbiWord 

Google 

Docs 

Google 

Calendar 

Gnome 

Evolution 

Fedora 

Windows 

osx 

(Wl|gpl|lgpl^ 

Opera  EULA 

(  GPL  ) 

Google  ToS 

Google  ToS 

(  GPL  ) 

r  GPL  ^ 

V  > 

MS  Eula 

License 

Design-time 
architecture: 
Browser , 
WP, 

calendar 


Instance 

Instance 

Instance 

Instance 

architecture: 

architecture: 

architecture: 

architecture: 

Firefox, 

Firefox, 

Firefox, 

Opera, 

AbiWord, 

OR 

Google  Cal., 

or  Google  Cal., 

or  Google  Docs , 

Evolution, 

Google  Docs, 

Google  Docs, 

Evolution, 

Fedora 

Fedora 

Windows 

OSX 

Opera  EULA, 
Google  ToS, 
Apple  License 


Figure  4.  A  Selection  Among  Alternative  Components  That  Can  Be  Included  at 

Build-Time  to  Produce  an  Integrated  System  Compatible  With  the  Design- 

Time  Reference 
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Figure  5.  An  End-User  Run-Time  Version  of  the  Selected  Alternative  Components 
That  Fulfills  the  Design,  Where  the  Red  Hat  Enterprise  Linux  Operating 
System  (Lower  Right  Corner)  Can  Utilize  the  Security  Modules  Library, 
SELinux,  for  Coding  and  Enforcing  Mandatory  Access  Control  on 
Programs/Data  and  Other  Security  Capabilities 

Acquisition-time  requirements,  such  as  the  use  of  SE  Linux  and  the  use  of  HTTPS, 
could  be  satisfied  by  this  choice;  with  an  appropriate  architecture,  the  IP  licensing 
obligations  could  also  be  satisfied.  At  design-time,  the  functional  requirements  would  need 
to  be  satisfied  by  appropriately  specified  shims  inserted  among  the  principal  components, 
and  if  such  shims  could  be  designed  then  this  would  be  the  proof  that  the  acquisition-time 
nonfunctional  requirements  could  also  be  satisfied.  Figure  5  shows  a  run-time  view  of  this 
instance  architecture,  resulting  from  the  specific  OA  ecosystem  and  instantiating  the  overall 
ecosystem  of  Figure  3  and  the  software  product  line  of  which  the  software  system  is  an 
instance. 


This  instance  architecture  has  both  a  manageable  IP  license  regime  that  ensures  its 
openness  and  a  manageable  security  regime.  For  IP,  in  this  architectural  instance,  all 
component  versions  can  be  selected  to  use  permissive  licenses  (Web  browser,  Web  server) 
or  reciprocal  GPL  licenses  (word  processor,  e-mail,  calendar,  and  operating  system),  They 
are  cleanly  separated  by  dynamic  run-time  links,  which  are  types  of  connectors  that  do  not 
transmit  IP  obligations  or  rights,  though  they  do  allow  for  control  flow  integration  and  data 
flow  interoperation. 
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Figure  6.  A  Second  System  Configuration  Using  Alternative  but  Functionally 

Similar  Components 

Figure  6  outlines  an  alternative  system  configuration  and  the  instance  ecosystem 
that  produces  it.  This  instance  architecture  substitutes  services  for  components  in  the  case 
of  Google  Docs  for  the  word  processing  functionality  and  Google  Calendar  for  the  calendar 
functionality.  With  appropriate  shims  and  changes  to  the  architectural  topology  this 
combination  of  major  components  could  also  support  the  system’s  functional  requirements, 
and  because  the  services  are  accessed  through  client-server  connections,  which  block  the 
propagation  of  most  license  obligations,  there  are  a  number  of  ways  to  satisfy  the  IP 
constraints  imposed  by  the  component  and  service  licenses. 

This  alternative  configuration  also  highlights  possible  acquisition-time  concerns  and 
the  nonfunctional  requirements  and  security  license  issues  that  follow  from  them.  For 
example,  a  remote  service,  such  as  Google  Docs,  provides  benefits  and  imposes  costs  with 
respect  to  a  compiled  component,  such  as  AbiWord.  On  the  one  hand,  the  remote  service 
makes  some  qualities  easier  to  achieve  (data  sharing,  backup,  etc.),  but  on  the  other  hand 
may  make  some  qualities  harder  to  achieve  (data  security  over  a  network  connection  and  in 
the  “cloud,”  up-time  of  the  service,  little  or  no  control  over  when  new  versions  of  the  service 
are  used  compared  to  complete  control  over  when  new  versions  of  a  component  are 
integrated). 

•  Who  in  the  ecosystem  of  human  actors  for  this  system  has  the  right  to  make  the 
decisions  to  use  a  service  in  place  of  a  component,  or  one  component  version  in 
place  of  another?  What  obligations  are  they  required  to  satisfy  first?  These 
questions  are  of  concern  at  acquisition  time  and,  we  claim,  are  addressable  by 
acquisition  licenses  that  restrict  rights  and  impose  obligations  important  to 
system  acquisition  officers,  just  as  IP  licenses  do  for  IP  rights  and  obligations 
important  to  software  producers. 

•  When  can  these  decisions  be  made?  In  traditional  development  processes,  these 
would  occur  at  design-time;  but  in  the  larger  view  we  propound  here,  such 
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decisions,  or  rather  the  policies  or  acquisition  licenses  that  control  them,  are 
perhaps  more  properly  considered  at  acquisition  time.  As  we  see  in  Figure  7,  it  is 
also  possible  that  in  order  to  achieve  specific  security  qualities,  they  might  be 
made  at  build-  or  run-time,  in  response  to  specific  threats. 


Figure  7.  An  End-User  View  of  the  Alternative  Run-Time  System  Configuration 

Figure  7  shows  a  run-time  view  of  this  alternative  configuration.  To  the  end  user,  this 
system  appears  quite  similar  to  the  one  in  Figure  5,  and  the  differences  might  scarcely  be 
noticed,  which  raises  the  next  set  of  possibilities. 

Both  these  instance  architectures  specify  specific  alternatives  for  the  major 
components,  for  example,  Firefox  for  the  Web  browser  component.  But  which  version  of 
Firefox?  For  example,  it  is  quite  possible  that  both  the  instance  architectures  discussed 
above  could  be  implemented  using  either  Firefox  10  or  Firefox  11,  satisfying  all  the 
functional  requirements  with  no  change  to  the  instance  architecture  and  no  revision  of 
software  shims.  Who  has  the  power  to  decide  to  use  version  10  rather  than  version  11? 

How  late  in  the  software  process  can  this  decision  be  made?  For  example,  could  it  be  made 
as  late  as  system  startup  time  by  a  system  user,  in  response  to  a  particular  security  attack 
on  the  previous  configuration? 

At  the  conceptually  lowest  level,  the  advent  of  code  randomization  and  multi-variant 
software  executables  leads  to  the  possibility  of  substituting  essentially  equivalent  variants  of 
the  same  component,  most  obviously  at  build-time.  The  decision  to  substitute  one  variant  for 
another,  or  the  decision  to  allow  the  substitution,  can  be  made  through  the  entire  range  of 
development  times  from  acquisition  time  to  run-time.  The  substitution  can  be  put  into  effect 
by  a  human  actor  or  by  a  software  monitor  following  a  security  policy,  either  randomly  or  in 
response  to  specific  events  in  the  environment. 

Finally,  an  orthogonal  consideration  is  the  use  of  containment  vessels  to  encapsulate 
components  or  subsystems  within  a  virtual  machine,  to  monitor  and  control  interactions 
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among  components  and  subsystems  in  order  to  block  attacks  and  protect  vulnerable  parts 
of  a  system.  Figure  8  shows  a  screenshot  in  ArchStudio  of  a  design-time  architecture 
utilizing  eight  containment  vessels,  seven  for  individual  components  and  connectors  and  the 
eighth  for  the  group  of  components  and  connectors  associated  with  the  OS. 


Figure  8.  A  Security  Configuration  Alternative  for  the  Run-Time  Configuration 
Instance  That  Encapsulates  OA  System  Components  and  Connectors 
Within  Different  Virtual  Machines  (e.g.,  using  the  “Xen  Hypervisor 

Project,”  2012) 

For  security,  the  GPL’d  Fedora  can  employ  the  SELinux  capabilities  to  restrict  all 
shell/operating  systems  commands  through  mandatory  access  control  and  type 
enforcement  (see  Figure  8),  while  other  components  can  all  be  contained  within  one  (for 
minimal  security  confinement)  or  more  (for  increased  security  confinement  on  a  per 
component  basis)  Xen-based  virtual  machines  (again,  see  Figure  8).  The  interoperability  of 
SELinux  and  Xen  is  now  a  common  feature  of  many  large  Linux  system  installations  (e.g., 
Amazon.com  now  has  more  than  500K  Linux  systems  running  Xen;  “SELinux  on  Xen,” 
2012;  “Xen  Hypervisor  Project,”  2012). 

Discussion  and  Conclusions 

Our  goal  in  this  study  was  to  develop  and  demonstrate  a  new  approach  to  address 
challenges  in  the  acquisition  of  secure  OA  software  systems.  Program  managers, 
acquisition  officers,  and  contract  managers  will  increasingly  be  called  on  to  provide  review 
and  approval  of  security  measures  that  are  employed  during  the  design,  implementation, 
and  deployment  of  OA  systems.  We  seek  to  make  this  a  simpler  and  more  transparent 
endeavor.  This  requires  security  policies  that  are  appropriate  for  review  and  approval  during 
acquisition  by  people  who  may  not  be  expert  in  the  specifics  of  how  best  to  ensure  that 
secure  systems  will  result.  Our  view  is  to  address  this  need  by  investigating  how  best  to 
specify  or  model  system  security  in  ways  that  can  accommodate  security  as  a  continuous 
process  that  must  be  supported  throughout  the  system  acquisition  life-cycle  for  OA  systems 
(Scacchi  &  Alspaugh,  2008,  2011). 
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Our  efforts  reported  here  reveal  that  it  is  possible  to  employ  a  scheme  through  which 
complex  OA  systems  can  be  designed,  built,  and  deployed  with  alternative  components  and 
connectors  into  functionally  similar  system  versions  in  ways  that  allow  for  overall  system 
security  through  the  use  of  multiple  security  mechanisms.  We  described  a  scheme  for  how 
to  realize  and  specify  such  OA  system  configurations  in  ways  that  are  inherently  compatible 
with  existing  security  mechanisms,  and  this  scheme  does  not  assume  that  individual  system 
elements  must  be  secure  before  inclusion  into  the  secured  system’s  configuration.  Central 
to  our  scheme  is  the  incorporation  of  software  product  line  concepts  that  are  integrated  with 
security  mechanisms  in  a  coherent  way  that  is  amenable  to  automated  support  and 
acquisition  management.  We  also  provided  a  case  study  that  reveals  where  and  how  we 
specify  a  secure  OA  enterprise  system  product  line  in  ways  that  can  accommodate  the 
diverse  needs  of  software  producers,  software  developers,  system  integrators,  users,  and 
acquisition  managers.  What  remains  as  an  important  next  step  for  this  line  of  research  effort 
is  to  more  fully  articulate  how  to  simply  and  transparently  specify  OA  system  security  using 
streamlined  security  policies  using  the  kind  of  system  security  licenses  we  anticipate 
(Scacchi  &  Alspaugh,  2011),  as  well  as  designing  and  developing  a  prototype  automated 
system  that  can  support  the  modeling  and  analysis  of  OA  system  security  policies, 
alternative  version  OA  system  configurations,  and  different  OA  security  licenses. 
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Overview 

•  Challenges  of  securing  open  architecture 
(OA)  systems 

•  Specifying  security  requirements  for 
software  systems 

•  Case  study:  Specifying  secure  software 
product  lines  within  an  OA  software 
ecosystem  for  enterprise  systems 
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Challenges  of  securing  open 
architecture  (OA)  systems 
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Security  challenges 

•  Security  threats  to  software  systems  are  increasingly 
multi-modal  and  distributed  across  system 
components. 

.  Physically  isolated  systems  are  vulnerable  to  external 
security  attacks,  via  portable  storage  devices  like  USB 
drives,  modified  end-user  devices,  and  social 
engineering  techniques. 

.  What  makes  an  OA  system  secure  changes  over  time, 
as  new  threats  emerge  and  systems  evolve. 

.  Need  an  approach  to  continuously  assure  the  security 
of  evolving  OA  systems  that  is  practical,  scalable, 
robust,  tractable,  and  adaptable. 
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Software  systems/components 
evolve:  what  to  do  about  security? 


•  Individual  components  evolve  via  revisions  (e.g.,  security  patches) 

•  Individual  components  are  updated  with  functionally  enhanced 
versions: 

•  Individual  components  are  replaced  by  alternative  components; 

•  Component  interfaces  evolve; 

•  System  architecture  and  configuration  evolve; 

•  System  functional  and  security  requirements  evolve; 

.  System  security  policies,  mechanisms,  security  components,  and 
system  configuration  parameter  settings  also  change  over  time. 
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Current  security  approaches 

•  Mandatory  access  control  lists,  firewalls; 

•  Multi-level  security; 

•  Authentication  (including  certificate  authority  and  passwords); 

.  Cryptographic  support  (including  public  key  certificates); 

.  Encapsulation  (including  virtualization),  hardware  confinement  (memory, 
storage,  and  external  device  isolation),  and  type  enforcement  capabilities; 

.  Secure  programming  practices; 

.  Data  content  or  control  signal  flow  logging/auditing; 

•  Honey-pots,  traps,  sink-holes; 

.  Security  technical  information  guides  for  configuring  the  security 
parameters  for  applications  and  operating  systems; 

.  Functionally  equivalent  but  diverse  multi-variant  software  executables. 
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What  acquisition  research  is  needed 

for  security? 

.  How  to  verify  the  security  of  OA  system  designs 

throughout  acquisition  life  cycle:  system  development, 
deployment,  and  post-deployment  support. 


•  How  to  validate  the  effectiveness  of  OA  system  security 
measures  and  knowledge  of  vulnerabilities  into  the 
ongoing  development  for  systems  in  an  operational, 
testable  form  that  system  integrators  and  administrators 
can  employ,  and  acquisition  program  managers  can 
assess. 
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Specifying  the  security  requirements 

for  software  systems 
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Carefully  specifying  security  policy 

obligations  and  rights 


The  obligation  for  a  user  to  verify  his/her  authority  to  see  compartment  T, 
by  password  or  other  specified  authentication  process 

The  obligation  for  all  components  connected  to  specified  component  C  to 
grant  it  the  capability  to  read  and  update  data  in  compartment  T 

The  obligation  to  reconfigure  a  system  in  response  to  detected  threats, 
when  given  the  right  to  select  and  include  different  component  versions,  or 
executable  component  variants. 

The  right  to  read  and  update  data  in  compartment  T  using  the  licensed 
component 


The  right  to  add,  update,  replace  specified  component  Dina  specified 
configuration 

The  right  to  add,  update,  or  remove  a  security  mechanism 


The  right  to  update  security  policy  L. 
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Case  Study: 

Securing  software  product  lines 
within  an  OA  software  ecosystem 

for  enterprise  systems 
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Software  product  lines? 


•  When  functionally  similar  software  components, 
connectors,  or  configurations  exist, 

.  Such  that  equivalent  alternatives,  versions,  or 
variants  may  be  substituted  for  one  another, 
then 

.  We  have  a  strong  relationship  among  these  OA 
system  elements  that  is  called  a  software 
product  line. 
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Software  ecosystem  of  producers  and  the  software  components  for 

an  enterprise  system 
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Framework  for  specifying  multi-level 
OA  system  security  policy 


ISR 
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A  design-time  specification  of  an  OA  enterprise  system  that 
accommodates  multiple  alternative  system  configurations 
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Software  product  line  that  provides  alternative,  functionally  similar 
components  compatible  with  the  reference  design-time  architecture 
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A  build-time  deployment  selection  among  alternative  components  that 
produce  an  integrated  enterprise  system  within  the  product  line 
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A  security  capability  specification  encapsulating  the  run-time 
configuration  instance  via  multiple  virtual  machines  (e.g.,  using  Xen) 
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An  end-user  run-time  deployment  version  of  selected  components 
within  enterprise  system  product  line  utilizing  security  library, 
SELinux,  for  enforcing  mandatory  obligations  and  rights. 


0  Applications  Places  System  % 


EJie  Ed*  yievr  Hijtory  Bookmarks  Tool*  Help 

+  v  O  jfe  •  nttp  ttvoerrerneiproisiameiato/portdytontef*  pty* 


GAME  CULTURE  &  TECHNOLOGY  LAB 


1  ^  ♦ 


✓  X  ■  /  I 


Tfr  nnwon  alfif  Glare  OiMr  4  T«cTindtt«  Lift  i*  totfir »  wtti  ho»  gate  r»ru»rrir* 
rVNtr  ii'f'to*  <  and  Irctndoj*"!  can  tr  utlis  0  It*  ten*?*  md  tw>rn 

dtlftr*  Ttwrocusilor>rtBnntp8rBirttJt«ilnlrrrr1«nj  tuyjnd 

I  tm  «pi  wih  carfami  lt»  erf  »rd  pacta  art  and  acMti ca  iiLcatnnard 
•nfeiuinran,  it  caj*  an  irwicnrart  Itial  aunnti  dmiia  lt»n»  riaipanaoi  n  ■ 
Mda  r  aai^a  rt  a^cMImi 


Sait*  'k  inaaKran  in  l»l>  It*  Cana  l  ata  haa  baaai  pfryicUIr  t*a_nad  in  It* 

I'  I  -  |90TA}  h  20(0  aa  a-aUbntad  a  colocated  Uoltr  ti  Tha 

CaldMnia  ^-otikila  ha  Talacanrauncatan  and  kilcanateai  Tactaidogf  |  li) 


Ele  Lc»t 

Iflaw  jettons 

Search  t>lp 

6  v  | 

a 

m 

♦ 

"V 

New 

Sand  /  Receive 

r  1  ■ 

Previous 

Today 

Next 

Go  lb 

□  Caleodar*  Mc«i.r3«^r2Dio  Any  Category 

o«t  This  Computer 


^  Contact* 

_  Brthdays  fc  Amivers 


5«*cn  ift 


Monday  20  April 


Tasks 

Summary 


|ckclc  to  add  a  tmlt 


c 

Apr!  2010 

> 

1 

2 

-■ 

4 

5 

6 

7 

a 

9 

10 

11 

32 

13 

14 

15 

10 

17 

18 

19 

20 

21 

2: 

23 

24 

25 

E 

27 

26 

29 

30 

□c 


i  pin  £  1:00pm 

Propos  J  review  meeting 


■a  pm  3.00pm 

Work  on  JSS  paper  draft 

4  pm 

5P«n 

6pm 

■7  pm 

Rpm 


'■  □  □  Review  n 


Memos 

^  Summary 

jciick  to  add  a  me  mV 


aranBaBaiai 


■f  live  System  user  Mon  Apr  20.  3: soph  eg 


j  &  -  X 


E*a  EcPt  ^iear  Insert  Fgrmat  Jbol*  T&ble  Collaborate  Documents  Belp 

y  jfc  1  &  fc.  p  *  »s»* 

Normal  v  Times  Nee  Roman  •*-  12  v  2  J  ^  *  ==  =  ( 

■••!••  ?  •  •  ?  ■  J  •  <  •  * 

A  Composed  Open  Architecture  Software  System  at  Run-Timej 

**•*  #  £  # 


cM 


•  «*  a  »  •  ■ 


r—  lai  on 


Page.  IV 1 


Eifi  E(*t  V«w  Jormnal  labs  fcjolp 

»ra:d. static  itconfig 


e2fsck  xmtctl 

e2iwge  taltlog  l 

[  liveusenjl&caliost  sbin]S  pud 

l/sbla 

[liuausengiocalhost  cbin)S  ca  . ./solinux 

[llveuserflocalhost  sellnux]*  Is 

access  cnecfcreqprot  coapat  net 

eve  class  context 

Jbooleens  coneit  pending  bools  create 
|[tlvemerpiocalnost  sellneoc|S  [] _ 


deny  <«ikr*yMn  initial 

disable  load 

enforce  tender 


acts  nls 

TWll 


pollcyvors  user 

reject  i^knoun 
relabel 


|  liveus^rANocalhcst  .'se  V  GCTl  -  Mission  M02II  GJ  Calendars  E  volition  ,  «JS5.figue4  draft  ab* 


Updated  post-deployment  system  configuration,  using  alternative  but 
functionally  similar  components  within  enterprise  system  product  line 


Instance 

architecture: 

Firefox, 

AbiWord, 

Evolution, 

Fedora 

GPL 


OR 


Instance 

architecture: 

Firefox, 
Google  Cal., 
Google  Docs, 
Fedora 


OR 


Instance 

architecture: 

Firefox, 
Google  Cal., 
Google  Docs, 
Windows 

MPL,  Google 
ToS,  MS  EULA 


Instance 

architecture: 

Opera, 

or  Google  Docs, 
Evolution, 
OSX 

Opera  EULA, 
Google  ToS, 
Apple  License 


OR  .. 


Firefox 


Opera 


AbiWord 


Windows  OSX 


Browser, 

WP, 

calendar 


MS  Eula  Apple 

License 


GPL 


(mPL|GPL|LGPl)  Opera  EULA 


Design-time 

architecture: 


Institute  for  Software  Research 

University  of  Caufornia,  Irvine 


19 


An  end-user  view  of  the  updated  alternative  run-time  system 

configuration 
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Discussion  and  conclusions 
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Discussion 


.  Our  goal  is  to  develop  and  demonstrate  a  new 
approach  to  address  challenges  in  the  acquisition  of 
secure  OA  software  systems. 

•  Program  managers,  acquisition  officers  and  contract 
managers  will  increasingly  be  called  on  to  provide 
review  and  approval  of  security  measures  that  are 
employed  during  the  design,  implementation,  and 
deployment  of  OA  systems. 

.  We  seek  to  make  this  a  simpler,  more  transparent, 
and  more  tractable  process. 
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Conclusions  (1) 

.  Our  research  demonstrates  how  complex  OA  systems  can  be 
designed,  built,  and  deployed  with  alternative  components  and 
connectors  into  functionally  similar  system  versions,  to  realize  for 
overall  system  security. 

.  We  described  a  scheme  to  specify  and  realize  OA  system 

configurations  that  are  compatible  with  existing  security  mechanisms. 

•  Our  scheme  does  not  assume  that  individual  system  elements 
must  be  secure  before  inclusion  into  the  secured  OA  system’s 
configuration. 

.  Central  to  our  scheme  are  software  product  line  concepts  integrated 
with  security  mechanisms. 


.  We  provided  a  case  study  that  reveals  how  to  specify  a  secure  OA 
enterprise  system  product  line  accommodating  diverse  needs  of 
software  producers  and  developers,  system  integrators,  users  and 
acquisition  managers. 
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Conclusions  (2) 


Next  steps: 

.  Articulate  the  process  how  to  simply  and  transparently 
specify  and  assess  OA  system  security  using 
streamlined  security  policies. 

.  Develop  and  demonstrate  a  prototype  automated 
environment  that  can  support  the  modeling  and 
analysis  of  OA  system  security  policies  and  alternative 
version  OA  system  configurations,  in  ways  that 
address  the  diverse  needs  of  acquisition  managers, 
system  integrators  and  end-users. 
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